| Review 1 | |
| PC member | Gilad Bracha |
| Overall evaluation |
Lopecode is a live document system based on Markdown, Observable and Javascript. It is a very
nice piece of work and I enjoyed reading about it. I am very much aligned with the idea of a self-modifiying web-based editor that is also a live IDE; given that I've built one myself, that should not be a surprise. The design principles are clearly articulated, and I am in complete agreement with them (and I've writen about them as well). Of course, using the system to write the submission is to be commended (and yet also expected,at least in the substrates community). And yes, it should have a self contained serializable format. Programmable prose: it goes almost without saying in such a system, but it is a very nice turn of phrase. Another point to be commended is including the AI critique. I agree on some of the points - relying on function printing is problematic. I would love to write an extended review that goes into the details, but time is limited, and there's no question that the paper should be accepted, so I'll keep it short. Question: you say Lopecode is a local first solution. I agree this is very desirable; but I'm not clear that Lopecode is truly local-first. It certainly runs locally, but what ensures synchronization across multiple clients? I find it valuable to compare Lopecode to Ampleforth, precisely because they are quite close philosophically. Key differences: Lopecode uses a reactive model. This is very attractive. In Ampleforth, reactivity is more ad hoc. The Newspeak UI frmaework is reactive, and one can layer reactive cells on top (I did a naive experiment on this called Ozymandias). Integrating a computaional notebook with a liev IDE addresses many of the well known limitations of these notebooks (Observable improves upon Jupyter, but not nearly enough; Lopecode clearly takes things to another level). Lopcode does not incorporate a programming language as such. Rather, it uses Javascript, effectively extended to be reactive by forcing its use in cells al computational notebooks. As a programming language designer, I find the use of Javascript distasteful. It also complicates support for live programming, modularity and security. I suspect the latter two are non-goals for Lopecode, but I am intrigued as to how you support true liveness using Javascript, and what are the trade-offs/costs/limitations this implies. Lopecode uses Markdown, extended with the ability to insert DOM nodes. Ampleforth uses HTML directly. Using Markdown simplifies amtters immensel. Ampleforth supports bi-directional editing, and doing this for fully general HTML is a Sysephean task that invites bugs and instability. The use of HTML was largely motivated by the desire to support general purpose embedded DOM trees. Frankly, the idea of incorporating a Markdown extension for DOM had not occured to me. I suspect it also entails limitations - what happens if a Lopecode document is embedded in one of these nested DOM elements? Does this compose properly? Overall, a great system. Choices are more pargmatic than mine - but that has allowed you to produce something mores solid. To be nit-picky, I think an academic submission should discuss related work, give citations and so on. Some of these appear almost inadvertantly (as in the acknowledgements section) but there is a reason for the classic framing of research papers. Related work, future work, conclusions are all valuable. None of which substantially detracts from this excellent submission. |
| Review 2 | |
| PC member | Clemens Nylandsted Klokmose |
| Overall evaluation |
Lopecode is an impressive piece of software that bundles a whole user programmable web document
in an HTML file that can be run offline and shared as a single file. The program is self-modifiable and based on the reactive paradigm adopting the Observable Runtime from Observable notebooks. It is quite the technical feat to demonstrate that this is practically doable. I also believe that it is very right minded that Lopecode is not just designed for human authorship, but can integrate with an AI that can interact directly with the runtime environment. There are a couple of things that provoke me with Lopecode, and I think would be great points for discussion at the Substrates workshop. First of all, I simply do not believe in software for the individual. It is hard to see how Lopecode would support collaboration whether synchronously or asynchronously. This connects to my next point, which is that while Lopecode admirably reduces the divergence (Basman et al., 2016) between code and content, it still has a divergence between document state and runtime or application state. This means that it is, as I understand it, difficult to share a Lopecode program with application state. Also, this divergence is reflected in that the edited state of the runtime of the whole document lives in memory until it is explicitly saved where only the document state is actually persisted in a shareable form. But this requires quite the understanding to realise this. This bit about understanding leads me to the third and final thing that provoked me. I admire Dan Ingalls a lot, but I am not sure I agree with that quote anymore. > If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual… Any barrier that exists between the user and some part of the system will eventually be a barrier to creative expression. Any part of the system that cannot be changed or that is not sufficiently general is a likely source of impediment. It is haunted by this notion of the single individual, and who is this single individual who does productive work in the society they are embedded in and has the desire, specialisation, luxury, and collective acceptance to spend time on entirely comprehending the system they are using to do so? I appreciate Lopecode as a technical exercise and proof-of-concept of a self-hosted reactive malleable system in one durable HTML file, but I do not know who this is for, what they would use it for, and why. I hope we can get to discuss that at the workshop. References: Basman, A., Church, L., Klokmose, C. N., & Clark, C. B. (2016). Software and How it Lives On-Embedding Live Programs in the World Around Them. In PPIG (Vol. 19, pp. 25-27). |
| Review 3 | |
| PC member | Gamithra Marga |
| Overall evaluation |
I found this genuinely exciting! The runtime being the source of truth is philosophically and
politically significant, and collapses a distinction that is seldom questioned. A lopecode
document feels precious, handing someone a living thing, a different kind of artefact that is
fully and perfectly self-containing. The demo format works very well, it was easy to try out and
play around with! Regarding use cases, the paper focuses mostly on programmer productivity. I'm excited about adjacent applications, like civic/policy documents, educational tools, or investigative journalism pieces where readers can modify assumptions of an analysis and re-run it themselves within the context of the story itself. I wonder if the project already has a theory of who these tools could eventually reach, and what it would take to reach them? The implied user throughout is a programmer -- while claiming radical accessibility (no network, no installation, no server) -- is the vision to replace that requirement? I don't think this weakens the work, and the malleability of the document itself would allow tailoring it to a broad audience, but I think the accessibility question is worth pondering. Overall -- substantial, well-executed, and a genuinely novel architectural commitment. Happy that it proposes something real, demonstrates it working, and opens new generative directions. |
| Review 4 | |
| PC member | Stephen Kell |
| Overall evaluation |
There's a lot going on in this submission, which is a tour/dump of the design, vision and
capabilities of the Lopeode system. I'm confident it'll be of interest at the workshop. I found myself reading the intro out of order: "Simplifying the programming process" was useful and then "The architectural principles" to give me some reference points to other systems. Still I think being even more comparative could get the audience on-message more quickly... e.g. I am often asking myself things like: is there a combination of features/properties that make Lopecode unique, and why have they not occurred together before? "Embedded AI" -- perhaps say something more focused about what this is / isn't? Does the "multi-document" design undermine the "resists bit-rot" thing? What is the interface between different documents? Or what is assumed about how they are kept in sync? The machine/OS analogies (userspace, bootloader, microkernel, etc) are intriguing. Can you perhaps also analogise the *differences* from booting an OS on a machine? Where (if at all) does Lopecode diverge from booting a conventional OS? I suspect the main answer is reactivity, i.e. OSes provide few or no reactive abstractions (cf. files that are passive, processes that are merely "active", etc). Is the vision that Lopecode would host single self-contained or could a Lopecode instance host large multi-creator systems of multiple parts? If the latter, where is (or might be) the boundary of one Lopecode instance? The tone is maybe slightly more sales-pitchy than is productive, but that is a minor comment. For "landing well" more generally, it might be useful to edit the text down quite brutally if you can bear it (say aim for half the length) and work on making it really focused. E.g. in the opening I was struck that: "it resists bit-rot because it's a local-first, single HTML file that works without network" is not really coherent argument-wise (local-first systems can still suffer bit-rot)... but later on the text does re-state this more carefully in terms of being self-contained except for long-lived standard dependencies which tend to be preserved well (in HTML browsers, etc). So maybe it'd be possible skip the earlier bit of text that is not hitting the nail quite so carefully? That's one idea but other deduplicating / "editing for focus" is likely possible and would help readability. |